Subject: Re: no can do

From: Choon Lee <[email-masked]>
Date: Fri, 13 Aug 1993 08:46:56 -0700

Hello, Scott,

I apologize for not making it clear at the outset what loop we are trying
to prevent.

>> You've addressed here an issue that I've found a little confusing for
>> some time...that is, what exactly are we trying to prevent loops in?

The loop we're trying to prevent is the case of a broadcast frame like the
TEST frame from getting into the DLSw cloud, getting out, and going back in
again indefinitely.

Consider the following scenerio,

  X-|                          |-Y
    |  -----            -----  |
    |--| A |--- DLSw ---| B |--|
    |  -----            -----  |
    |  -----            -----  |
    |--| C |--- DLSw ---| D |--|
    |  -----            -----  |
LAN A                         LAN B

When a TEST frame is generated by station X on LAN A to station Y, it causes
DLSw A (lets forget DLSw pair C and D for now) to create a SSP CANUREACH to its 
DLSw partner, B. B will then send a TEST frame (DA=Y, SA=X) out on LAN B. This
TEST frame also gets to D. D didn't know any better, and will generate another
SSP CANUREACH to C, causing a similar TEST frame to be generated back on LAN A.
And this go on forever.

In the event of source routing TEST frames (e.g. LANs A and B are token ring), the
frames have routing information. As a result, TEST frames that gets out from
the DLSw cloud (e.g. the TEST frame that B puts on LAN B) has a virtual ring 
number (as mandated by the DLSw cloud). This frame cannot subsequently get back
into the cloud (via D).

So, if we have a loop prevention algorithm that turns the link between C and D
into a BLOCKING state, this recirculation of frame can be prevented. A link
in such a BLOCKING state is supposed to block data traffic on the TCP connection.

Regards,
Choon Lee
3Com Corp